For those who don't know,
Rails Rumble was a 48-hour programming contest where teams of 1-4 built and deployed web applications using Ruby on Rails. It's the new version of last year's Rails Day, which was 24-hours but didn't require deployment. Rails Day 2006 had some hiccups as well as some serious judging problems (it took almost 4 months for juding to finish). However, Rory and I enjoyed Rails Day, so we decided to try Rails Rumble.
Here's what I liked about them, and why I generally enjoyed them both:
1. Working in groups is fun
2. It's cool to see what other people can do
3. It really stretches your programming muscles to do everything so fast
4. It doesn't have to be perfect, so it's easier to experiment
And here's why I won't be participating in 2008. These require a little more explanation.
1. It was poorly organized
The organizers only expected about 50 teams, even though 150 teams signed up for Rails Day last year (170 signed up this year), which led to slow-downs. Also, some things (like the voting changes) were only mentioned on IRC, making it difficult to know what was going on. They were also late to start the initial signup and voting, although those weren't big problems
2. 48 hours is too long
Working so hard for an entire weekend meant I was pretty worthless on Monday. I also had to bail on some other commitments (partly because the contest was announced late; see above). The only reason I've heard to keep it 48 hours is to keep deployment in the contest. Deployment doesn't seem like it should be a big part of the contest. Nobody had an application that just didn't run, so it wasn't a differentiator. The organizers have said that they think it's important to show people that Rails can be deployed easily, but the contest doesn't really address that (since we were given much nicer hosting than most people who have trouble deploying Rails).
3. The judging system was poor
Last year, voting was done by a set of judges who also looked at the code. This year, people could sign up to become judges and then rank applications on a 1-5 scale in four categories. Basically, that just makes it a popularity contest. After voting was done, the organizers decided to toss out anyone who voted all 5s on a single application (which was a poorly thought-out and communicated decision; see above) to address this. Of course, that doesn't stop people from voting all 5s on one app and all 1s for the rest. A better system would have pre-defined judges or use the
Jay is Games system where casting a vote requires a donation towards that application. However, the organizers don't seem to feel that voting was a problem, so they probably won't change it significantly.
4. The rules reward "useful" applications, which stifles creativity
Almost all of the winning applications are just copies of existing applications (although well-done). In fact, the winning application is a recipe site, which is a common tutorial topic for Rails (some of you may remember the Kitchen Knight, which was my own take on it). I'd much rather see some crazy applications than yet another checkbook application, but that's not what the scoring system rewards.
Overall, congratulations to everyone who entered and good luck to the organizers next year! Just don't expect to see me there.